As mentioned in #80, there were issues when initializing the Stat objects. Looking further into it, I found that the dirEntries was called to get the directory entries. However, it simply iterates through the keys of the Index. Since the Index object is in the process of being created when this is called, not all keys which would otherwise be in the final Index object are there when it's called.

I also found the bug which caused the double unlocking bug. This occurs if the program locks a path 3 times.
On it's first lock, it would creates a Promise 'A'. Then when it locks a second time, it awaits Promise 'A'. Finally on it's third time, it would also await Promise 'A'. When the program unlocks the lock (resolving Promise 'A'), both threads which are awaiting 'A' start running at the same time, which causes the bug.

@terryluan12 Some changes have been made. Primarily, the Mutex logic has been folded into LockedFS. Please consult the release notes for v0.14.0.

Ah, didn't even notice it, thanks for the heads up! I just merged + re-added the changes

As mentioned in #80, there were issues when initializing the Stat objects. Looking further into it, I found that the dirEntries was called to get the directory entries. However, it simply iterates through the keys of the Index. Since the Index object is in the process of being created when this is called, not all keys which would otherwise be in the final Index object are there when it's called.

This should have been resolved in ec86a6a. Please let me know if the issue still happens- you will need to run make-index again. I am against using a regex since it is relatively slow. If one was to have 10,000 files for example, creating a new regex for each one slows things down.

@terryluan12 Any updates on this?

@terryluan12 Any updates on this?

Hi @james-pre, so sorrry about the lack of update! Got busy with some real life stuff, and didn't see the comments. Just got a replacement for my previous laptop, and will get to work on zen-fs, and finish up this issue ASAP

Hey @james-pre, I've been taking a look at the double unlocking issue, and I've gotten an idea of why it's bugging. Specifically, it occurs when you have two processes waiting on a locked promise. Once the promise resolves, both processes will continue at the same time. Thus they'll both call addLock, and one promise will override the others, causing the weird double unlocking. Thinking about it, I think one possible solution is to implement a queuing system. What are your thoughts?

@terryluan12,

Thanks for your dedication to this.

My thinking is that we should try to avoid a queue system.

It should work like this:

• call asynchronous methods a and b on the same path without using await,
  • i.e.

   	a(path);
   	b(path);

• a locks on the path, which adds the lock
• b tries to lock on the path, though it must wait for a to finish (in LockedFS.lock)
• a performs its operations
• a's scope is left, MutexLock[Symbol.dispose] runs, unlocking the path
• b then performs its operations
• b's scope is left, MutexLock[Symbol.dispose] runs, unlocking the path

I think e387889 may fix something since now the promise won't resolve until the lock is actually cleared.

No worries at all, thanks for allowing me to help!

I think there's been a misunderstanding. To clarify, the issue occurs in the following scenario, when there are 3 locks; for example A, B, and C.
In this case, if A locks first, and then B and C lock (in any order), then both B and C are now waiting on A's lock to release.

When A then releases, both B and C start again at the same time. I believe this is the unintended behaviour, where they both start again at the same time.

Ah, this makes more sense now! Thanks for the clarification.

Maybe we could look at a wrap and replace, so when B attempts the lock, it replaces the current lock with one that resolves when B is done. This wouldn't impact A since it holds the lock, and doesn't update the reference (i.e. the A's MutexLock[Symbol.dipose] resolves only the lock for A).

@terryluan12 Now that the mutex issue has been solved, can I close this PR?

Yep, absolutely!